Fill in the CF-5 stub with the full escrow-lock algorithm
(docs/cashu/02-track-a-lock.md §4). A `cashu`-mode node now accepts a
seller's `AddCashuEscrow`, fully validates the 2-of-3 token against the mint
and the order's trade keys, atomically advances `WaitingPayment → Active`,
publishes the updated order event, and notifies the buyer to send fiat.

Validate-fully-then-commit discipline (same as `release_action`):

1. resolve the order;
2. authorise the sender == the order's seller trade key (else `InvalidPeer`);
3. require `WaitingPayment` status;
4. extract the `CashuLockProof` (absent ⇒ `InvalidCashuToken`);
5. bind the mint: `proof.mint_url` must equal the configured mint
   (`InvalidMintUrl`) — a cheap pre-check; step 7 enforces the authoritative
   token↔mint binding;
6. bind `{P_B, P_S, P_M}` to THIS order — reject a proof whose stated keys
   disagree with the order, and derive the keys handed to the mint from the
   order (never from the proof), so the 2-of-3 can only lock to keys Mostro
   already holds;
7. `verify_escrow_token` (2-of-3 + seller-recovery locktime floor
   `now + escrow_locktime_days` + mint + amount + DLEQ + unspent); mint
   unreachable ⇒ `CashuMintUnavailable`, malformed ⇒ `InvalidCashuToken`;
8. `update_order_cashu_escrow` CAS (lock + status advance in one write);
   zero rows ⇒ idempotent no-op (replay/concurrent), no notification;
9. publish the Active order event (best-effort, logged on failure);
10. notify buyer + seller with `CashuEscrowLocked`.

The escrow token locks `order.amount` exactly (Option 2 — the Mostro fee is a
separate token added in TA-1f).

Tests: the deterministic pre-mint rejection paths (wrong sender ⇒
`InvalidPeer`, wrong status, missing proof ⇒ `InvalidCashuToken`) and the
`cashu_reason` error mapping. The mint-backed happy-path + replay tests are a
follow-up: they need a 2-of-3 token builder in the CF-3 harness (which today
ships only connectivity helpers).

Depends on CF-5 (dispatch seam + cashu_client). Base: feat/cashu-cf5-boot-integration
Refs: docs/cashu/02-track-a-lock.md (TA-1)

TA-1 implements AddCashuEscrow, so dispatch_cashu no longer routes it to
InvalidAction — it runs the real lock handler. Remove it from the
'blocks every order-lifecycle action' assertion list.

Add the Cashu branch to `take_sell_action`/`take_buy_action` and the
`show_cashu_escrow_request` helper (docs/cashu/02-track-a-lock.md §5), and
unblock `NewOrder`/`TakeBuy`/`TakeSell` in `dispatch_cashu`. A taken order on
a cashu node now asks the SELLER to lock a 2-of-3 escrow instead of paying a
hold invoice, leaving the order in `WaitingPayment` where the TA-1 CAS
expects it. Creatable and takeable ship together so the book never fills with
untakeable orders (the orphan-order hazard CF-5 warns about).

- `util::show_cashu_escrow_request`: advance to `WaitingPayment`, record both
  trade pubkeys, publish the order event, and enqueue an escrow request to the
  seller (`Action::WaitingSellerToPay` + `Payload::Order` carrying
  `amount`/`buyer_trade_pubkey`/`seller_trade_pubkey`) plus a bare "waiting for
  the seller" notice to the buyer. The buyer redeems ecash directly, so there
  is no buyer payout invoice. The escrow locks `order.amount` exactly (the fee
  is a separate token in TA-1f); the mint URL + locktime floor are node policy
  the daemon enforces authoritatively at lock validation (TA-1 §5/§7), so they
  are not carried in the request (the 0.14.0 protocol has no field for them).
- `take_sell`/`take_buy`: early-return through `show_cashu_escrow_request` when
  `is_cashu_enabled()`, skipping the hold-invoice / buyer-invoice path. A
  supplied buyer invoice is ignored in Cashu mode. Lightning path unchanged.
- `dispatch_cashu`: route `NewOrder`/`TakeBuy`/`TakeSell` to
  `handle_message_action_no_ln` (their real handlers); the gate test drops them
  from the `InvalidAction` list accordingly.

Test: `show_cashu_escrow_request` advances the status, records both pubkeys,
and enqueues the seller request (with the trade pubkeys + bare amount) and the
buyer notice.

Depends on CF-5 (+ TA-1 for the full e2e lock). Base: feat/cashu-ta1-lock-handler
Refs: docs/cashu/02-track-a-lock.md (TA-2)

On boot in Cashu mode, re-hydrate in-flight locked escrows from the DB (the
Cashu analogue of the Lightning `find_held_invoices` resubscribe) so a restart
never loses sight of a locked-but-not-released escrow
(docs/cashu/02-track-a-lock.md §6/§10).

- `CashuClient::check_token_unspent`: whether every proof of a stored escrow
  token is still unspent at the mint (NUT-07), fail-closed on a short state
  reply. Reuses the Y-derivation the lock path already uses; does not re-run
  the full acceptance check (the token is immutable and was validated at lock).
- `cashu_restore::restore_cashu_escrows`: list `find_locked_cashu_orders`, and
  for each re-check the token against the mint, logging a warning for any
  escrow that is spent/pending (redeemed or double-spent while the daemon was
  down). Best-effort, log-only — it never mutates order state (that belongs to
  the release/cancel/dispute tracks) and never blocks boot.
- Wired into the `main.rs` Cashu boot branch after the mint connects, before
  the scheduler starts.

Test: restore over an empty pool finds nothing and never contacts the mint.
The mint-backed spent/live detection is exercised by the CF-3 integration
harness.

Depends on CF-4 + CF-5. Base: feat/cashu-ta2-take-flow
Refs: docs/cashu/02-track-a-lock.md (TA-3)